home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9707 / 000032_owner-linux-arm…r.rutgers.edu _Thu Jul 3 20:13:37 1997.msg < prev    next >
Internet Message Format  |  1997-11-30  |  4KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id UAA27862 for <willy@odie.fluff.org>; Thu, 3 Jul 1997 20:13:36 +0100
  3. Received: from root@vger.rutgers.edu (port 19825 [128.6.190.2]) by nic.funet.fi with ESMTP id <2261-23894>; Thu, 3 Jul 1997 22:02:17 +0300
  4. Received: by vger.rutgers.edu id <1003652-30852>; Thu, 3 Jul 1997 14:51:30 -0400
  5. Received: from IDENT-NOT-QUERIED@server21.digital.fr (port 2678 [193.56.15.21]) by vger.rutgers.edu with ESMTP id <1003695-30852>; Thu, 3 Jul 1997 14:50:47 -0400
  6. Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by server21.digital.fr (8.7.5/8.7) with ESMTP id QAA31199; Thu, 3 Jul 1997 16:51:06 +0200 (MET DST)
  7. Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA15690; Thu, 3 Jul 1997 16:43:53 +0200 (MET DST)
  8. Received: from linux.reo.dec.com ([16.36.0.79]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA03581; Thu, 3 Jul 1997 16:25:13 +0200
  9. Received: from linux.reo.dec.com (localhost [127.0.0.1]) by linux.reo.dec.com (8.8.5/8.7.1) with ESMTP id PAA00498; Thu, 3 Jul 1997 15:41:33 GMT
  10. Message-Id: <199707031541.PAA00498@linux.reo.dec.com>
  11. To: "Neil A. Carson" <neil@causality.com>
  12. cc: Matthew Wilcox <willy@odie.barnet.ac.uk>, linux-arm@vger.rutgers.edu,
  13.         Charles Esson <charlese@cvs.com.au>
  14. Subject: Re: Re ELF 
  15. In-reply-to: Your message of "Wed, 02 Jul 1997 20:19:04 +0100."
  16.              <Marcel-1.09-0702191904-b07f3nA@succexpr.demon.co.uk> 
  17. Mime-Version: 1.0
  18. Content-Type: text/plain; charset=us-ascii
  19. Date:     Thu, 03 Jul 1997 15:41:32 +0000
  20. From: "Ka'Plaagh" <rusling@linux.reo.dec.com>
  21. Sender: owner-linux-arm@vger.rutgers.edu
  22. Precedence: bulk
  23. Status: RO
  24.  
  25. > On Wed 02 Jul, Matthew Wilcox wrote:
  26. > 
  27. > > No.  To flush the instruction and data cache, the recommended method is to
  28. > > read 32kB.  
  29. > 
  30. > No, only if you're silly. If you're clever, you only do 16Kb.
  31. > 
  32.  
  33. True.  Also you can flush the I cache with 1 instruction, you only clean D-cache.
  34. To clean it you need to map a lump of memory to a high virtual address (the 
  35. cache is virtually-tagged) and then read enough to evict all of the cache's
  36. previous contents.   The 21285 (aka Footbridge) support chip makes this easy
  37. by having an area of memory that does not actually exist, read cycles complete
  38. in no time and return 0.  This is precisely to make cleaning the D-Cache quicker.
  39.  
  40. > > > I don't think a task switch should involve cleaning up a 16k cache, if
  41. > > > it does performance will be pretty poor.
  42. > > 
  43. > > It isn't /that/ bad.  Other CPUs manage that, and considerably worse.  The
  44. > > problem is exacerbated by the RPCs slow memory bus, but it's still
  45. > > liveable with and it's considerably better than your alternative
  46. > > suggestion.
  47. > 
  48. > I diasgree. Not many CPUs need to do this and considerably worse, I can't
  49. > think of any mainstream ones to hand...
  50. > 
  51. > > This I see as a very bad idea.  It would mean all sorts of stupid
  52. > > restrictions on applications that don't exist under any other
  53. > > architecture.  You'd be limited to about 64MB per application and 48 tasks
  54. > > running simultaneously.  This is crap.
  55. > 
  56. > No, that is crap :-) Why are you limited to this?
  57. > 
  58. >     Neil
  59. > 
  60. > -- 
  61. > Neil A. Carson
  62. > Marketing Director              Causality Limited (London, UK)
  63. > Tel/Fax: +44 (0)181 930 7408    Mobile: +44 (0)370 593183
  64. > Email: neil@causality.com       WWW: http://www.causality.com.
  65.  
  66. ----------------------------------------------------------------------
  67. David A Rusling                Principal Engineer
  68. European Semiconductor Applications    Digital Equipment Co Ltd.,
  69.     Engineering            PO Box 121,
  70.                     Imperial Way,
  71.                     Worton Grange
  72.                     Reading RG2 0TU
  73. Linux, Alpha, StrongArm, PCI        Tel: UK-(0)1734-204380
  74.                     Fax: UK-(0)1734-203133
  75. ----------------------------------------------------------------------
  76.